IBIS Macromodel Task Group

Meeting date: 08 December 2015

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI):                  Xingdong Dai
                            * Bob Miller
Cadence Design Systems:       Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
Cisco:                        Seungyong (Brian) Baek
eASIC:                      * David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
GlobalFoundries:              Steve Parker
Intel:                      * Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.:                 James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys:                     Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong


The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- Arpad reviewed upcoming ATM meeting dates, noting last week's decision
  to cancel meetings on December 22nd and 29th.  He also proposed that we
  cancel the meeting on January 19th because DesignCon and the associated
  IBIS summit occur that week.  The group decided to cancel the meeting on
  January 19th, 2016.

--------------------------
Call for patent disclosure:

- None.

-------------
Review of ARs:

- None.

-------------------------
Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Michael M.: Second.
- Arpad: Anyone opposed?  [none]

-------------
New Discussion:
  
Discussion of language corrections regarding "ground":
- Walter: [Reviewing "GND BIRD" presentation from 30 Jun 2015, to which
           Walter had added one new paragraph on page 4 (below)]
  - New paragraph:
    "GND is used in many places in this document as the signal_name of Pins that
    have Model Name GND. GND in many "buffer example schematics" use this name
    GND as a signal name such as VCC, VDD, VSS. The string GND in this document
    shall refer to either a Model Name in the Pin list or a signal name on one
    or more pins that coincidently also have Model Name GND. GND shall never be
    interpreted as the reference node in many SPICE simulators that is often
    called Node 0. Since IBIS defines signal_name as a component Data Book Name,
    we must assume that all Pins that have Model Name POWER or GND and have the
    same signal_name are assumed to be connected together on the components
    board or module. Each buffer can have one or two ground terminals (pdref
    and/or gcref) that are local nodes of the of the power distribution circuit
    of Pins that has Model Name GND. [Pin Mapping] is required to determine
    which signal_name is the local ground nodes of each Buffer."

- Discussion: Walter stated that if we could agree on the new paragraph, then
  he thought things would be straightforward.  Walter reiterated that Section 3
  "GENERAL SYNTAX RULES AND GUIDELINES" in the spec stated that GND "must not be
  used" for anything other than the reserved model name used with ground [Pin]s,
  and that this statement had been violated repeatedly in the spec.  He felt his
  new paragraph captured the ways GND had actually been used.  Walter further
  explained his paragraph, and summarized by stating that in the IBIS Spec, GND
  is used as a reserved model name or as a signal name.  Walter stated that his
  preference was to replace GND with VSS wherever it was used as a signal name,
  but he recalled that others had objected to that.
- Arpad: I partially agree, but the spec does not prevent anyone from using GND
         as a signal name on a [Pin] that has a different [Model] name than GND.
- Walter: Nothing prevents it, but in the spec it's only used one of two ways.
- Radek: GND was also used in the context of a node in a schematic figure.
  - These had been replaced by ground symbols [mistakenly] when new figures
    were created.
- Walter: In each of those instances, where GND is used "Vcc" is also used.
  - Vcc is a signal name.
  - In every case GND probably references a [Pin] where GND is a signal name.
  - The intent is that it's a node in the schematic with a low impedance
    connection to a [Pin] with signal name GND.
- Bob R.: I think that's as far as we should go.
  - State that it's a reserved model name or a signal name.
- Mike L. - Doesn't this mean that every place GND is used in the document we
            should say GND model or GND signal?
- Walter - Our task in this review is to make sure it is clear in each context
           that it's a model or a signal.
- Discussion: Walter stated that since IBIS defined a [Pin]'s signal name as the
  data book signal name, we can rely on two [Pin]s with the same signal name
  being connected.  He asked if anyone disagreed that if two pins in the data
  book had the same signal name that they were in fact connected somewhere in
  the package?  Arpad said he wasn't sure.  Mike L. said it might not be
  specific enough, and that two pins with the same name meant they couldn't
  be assumed not connected, but might not guarantee they were connected.
- Arpad - What is meant by "assumed to be connected"?
  - Everything is connected.  The question is where and how.
- Walter - We agreed that "connected" means a low impedance path between them.
- Arpad: I could see two different groups of VCCH coming from totally different
         VRMs.
- Walter: If they wanted to partition VDD, they would do things like VDDA, VDDB.
  - This is done a lot with memory chips where you have VDD and VDDQ.
  - If we can't agree that [Pin]s with the same signal name are connected, then
    this attempt to clarify GND is an impossible task.
- Arpad: Why does everything hinge on this statement?
- Walter: If you use GND or VDD on a schematic, it just means it's connected
          to one of the [Pin]s with signal name GND or VDD.
  - That's what [Pin Mapping] does in essence.  It says, for this particular
    buffer instance, its pu_ref is signal name VDD.
- Bob R.: Global statement should mention that GND or VDD could be bus labels.
- Walter: Each buffer can have one or two ground terminals (pd_ref, gc_ref).
- Bob R.: Theoretically, any of the reference terminals could be used.
- Walter: As a practical matter, almost every buffer has just one, pd_ref or
          gc_ref.
  - There are unusual cases where it's not true.
  - These connections to the buffer are local nodes of the power distribution
    circuit of [Pin]s that have model name GND.
  - [Pin Mapping] is required to tell us which signal name or bus label is the
    local ground node of each buffer.
  - Without [Pin Mapping] we don't know how to connect C_comp because we don't
    know which [Pin] C_comp has to be connected to though the power distribution
    network.
- Arpad: There is a special case in which [Pin Mapping] is not needed.
  - If the [Component] has only one Power and or one GND [Pin], it is clear.
- Walter: Yes there is a special case.
  - If the [Component] only has one signal name associated with [Model] name
    GND, it could be multiple [Pin]s, and one signal name associated with
    [Model] name Power then we would know the local references for every buffer.
- Discussion: Arpad asked if we had to worry about when [Voltage Range] was
  specified in lieu of the four reference values [Pullup_ref], etc.  Walter said
  that those values merely specified the voltages found at the reference nodes
  while I/V and v(t) were measured.  Bob R. agreed.
- Walter: If we accept this, then we just have to:
  - Go through the spec and look for GND.
  - Revert schematics where GND was improperly converted to a ground symbol.
  - Deal with A_gnd and a few other things.
- Walter: The point is that every device has its local ground.
  - All the I/V and v(t) are relative to that local ground.
  - Anything but 0 for [Pulldown Reference] or [GND Clamp Reference] is a
    meaningless concept.
- Radek: That is not entirely true.
  - If you have a [Pulldown Reference] that is non-zero, then the v(t) tables
    include that offset.
  - I/V characteristics are the same, but for v(t) tables that is not true.
  - We really have to define what that local reference, I/O reference, is.
  - Original IBIS never did this.
  - Aside from [Pin Mapping] there was never any relationship between local
    ground for a specific buffer with respect to any ground pins.
- Walter: When you measure, what is the voltage at the I/O referenced to?
  - The only thing that makes sense to reference it to is the local ground.
    - Input - gc_ref node.
    - Output - pd_ref node.
    - I/O  - one or the other.
    - Once you have power aware simulations, this has to be defined.
- Discussion: Bob R. objected to Walter's proposal to specify that gc_ref or
  pd_ref nodes were the local ground reference.  He only wanted to state that it
  might be any one of the local reference nodes, and provided ECL as a counter
  example.  Walter said we could add special cases.  Radek said that if we
  didn't specify it then we ran the risk of inconsistent interpretation.  Arpad
  suggested that we come up with a way to specify what the reference was, and
  stated that he was uncomfortable with Walter's assertion that GND in the
  schematic always referred to a GND signal associated with a ground [Pin].
  Walter responded by reviewing various figures in the spec (ISSO figures among
  others) and pointing out that where GND was used the figures also used
  signal names like VDD.
- Arpad: How should we move forward?
  - Do we have agreement, even on the problem statement?
- Bob R.: We have identified exceptions to the "must not be used."
  - Bus labels, signal names, are perhaps the exceptions.
  - I would vote against it now though.  It has too much stuff in it.
  - Some is contradictory to some existing [Model]s.
  - Separate the notion embedded in this that local ground must be tied to one
    of the pd_ref or gc_ref nodes.
- Arpad: We will continue the discussion next week.
  - Thank you all for joining.

-------------
Next meeting: 15 December 2015 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
